Private Access Point Containing a Sim Card

ABSTRACT

An access point, or base station, for a mobile communications network, such as a cellular communications network, can be installed by a user, for use within or close to their own home or office. The base station has a SIM card, and can establish secure communications with the core network of the mobile communications network over the user&#39;s existing broadband internet connection. The base station is also able to obtain the necessary ciphering keys, in order to allow the mobile device to communicate securely with the base station, and hence with the core network.

This invention relates to an access point, and in particular to anaccess point for a mobile communications network.

It is proposed that, in order to allow an operator of a mobilecommunications network, such as a cellular communications network, toincrease the coverage area of the network, users should be able toinstall access points, or base stations, for use within or close totheir own homes or offices. Such base stations can establishcommunications with the core network of the mobile communicationsnetwork over the user's existing broadband internet connection.

In order to achieve this, it is necessary for the base station to beable to communicate securely with the core network of the mobilecommunications network, and to allow a mobile device communicating withthe base station to communicate securely with the core network.

According to a first aspect of the present invention, there is provideda base station for a cellular communications system, comprising aninterface for a SIM card.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block schematic diagram of a system incorporating a basestation in accordance with the present invention.

FIG. 2 is a block schematic diagram illustrating the hardwarearchitecture of a base station in accordance with the present invention.

FIG. 3 is a block schematic diagram illustrating the softwarearchitecture of a base station in accordance with the present invention.

FIG. 4 is a block schematic diagram of a further system incorporating abase station in accordance with the present invention.

FIG. 5 illustrates a conventional network architecture.

FIG. 6 illustrates a network architecture in accordance with an aspectof the present invention.

FIG. 7 illustrates a signalling procedure in accordance with an aspectof the invention.

FIG. 8 is a block schematic diagram of a part of the further system ofFIG. 4 in use.

FIG. 9 illustrates a further signalling procedure in accordance with anaspect of the invention.

FIG. 10 illustrates a further network architecture in accordance with anaspect of the present invention.

FIG. 11 illustrates a further network architecture in accordance with anaspect of the present invention.

FIG. 12 illustrates the further network architecture of claim 10, inuse.

FIG. 13 illustrates a further signalling procedure in accordance with anaspect of the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

FIG. 1 is a block schematic diagram, illustrating a system architecture.A mobile network operator (MNO) owns and operates a wirelesscommunications network, including a radio network 10, including anetwork of cellular basestations (not shown), and a core network 20,having a connection into the fixed telephone network. These aregenerally conventional, except as described below.

A mobile phone 30, when roaming in the territory covered by the wirelesscommunications network, is able to establish a wireless connection withone of the cellular basestations, in order to communicate with othertelephones in the fixed telephone network, or with other mobile phones,which have established their own wireless connections with a cellularbasestation, and hence with the fixed telephone network.

In accordance with the present invention, there is provided, for examplewithin a home or office 40 or in another location where additionalwireless coverage is required, a further basestation, or access point,50. This access point 50 is provided for use by the owner of thepremises where it is located, but is integrated into the wirelesscommunications network. That is, the access point shares the part of theradio frequency spectrum allocated to that wireless communicationsnetwork, by having allocated to it, either permanently or temporarily,some of the group of channels. This group of channels is thus sharedwith other basestations, which may serve macrocells, microcells,picocells, or even “femtocells”, in the public, wide area network. As aresult, the mobile phone 30 can roam from the access point 50 to anotherbasestation when leaving the immediate vicinity of the access point 50,or can roam to the access point 50 from another basestation whenreturning to the immediate vicinity of the access point 50.

The access point 50 therefore acts as a basestation within the relevantwireless communications network. For example, it can allow an entirelyconventional and unmodified mobile phone 30 or other user device toestablish a connection for voice and/or data services using GSM/GPRSand/or UMTS air interfaces. Of course, the access point 50 can beenabled to establish connections with the mobile phone 30 using thestandard air interface of any suitable cellular wireless communicationssystem.

The access point 50 has a connection for an Ethernet Local Area Network(LAN) 42, within the home or office 40. As shown in FIG. 1, the accesspoint 50 can connect over the Ethernet LAN 42 to one or more local PCsor servers 44.

The access point 50 can connect over the Ethernet LAN 42 to an IPgateway device 60. The IP gateway device 60 provides an IP connectionover an IP network 70, for example the internet, to the MNO networkeither via a Digital Subscriber Line (DSL) or via other IP transportmethods such as a digital multimedia Cable network. Thus, the existingIP connection from the home or office can be used to provide backhaulfrom the access point 50. Flexible interfacing to the operator's corenetwork 20 can be provided via connections to either the MNO CoreNetwork or Radio Access Network, using the UMA standard through a UMAgateway 22. This approach enables low-cost transport of data and voiceusing Voice-over-Internet Protocol (VoIP) techniques.

The connection from the IP gateway 60 over the IP network 70 into theMNO Radio Access Network 10 is provided by a UMA Unlicensed NetworkController (UNC) 12, which has been standardised by 3GPP as a GenericAccess Network Controller (GANC). Other non-standardised solutions tointerface to the Radio Access Network 10 could also be employed as analternative approach. Direct connection to the operator's Core Networkcan be achieved through use of a SIP Interface between the access pointand a suitable gateway such as a SIP Gateway or an IP MultimediaSubsystem.

In this illustrated embodiment, the DSL or cable IP gateway device 60includes provision for connection of a POTS telephone or fax device 62,and audio/video connections for providing IPTV services to a TV 64. Theaccess point 50 includes a services environment which allows thesefacilities to be integrated into the MNO network, enabling sophisticatednew services for users.

In an alternative implementation of the invention, the access point 50can be integrated as a component within the IP gateway device 60; aninternal IP connection then links the embedded access point component tothe router functions within the IP gateway device. This configurationcan potentially provide a lower overall cost and is convenient foroperators looking to provide gateway units which unify data, fixedvoice, multimedia and mobile services.

Thus, while the mobile phone 30 is within the home or office 40, orotherwise within the coverage area of the access point 50, it canconnect into the MNO network in the same way as via any otherbasestation in the cellular wireless communications network.

FIG. 1 also shows a network server 72 connected to the IP network 70. Aswill be appreciated, where the IP network 70 is the internet, a verylarge number of servers and other devices are connected to the network.As will be described in more detail below, the user of the mobile phone30 can access such devices by means of the access point 50.

FIG. 1 also shows a management system 74, connected to the IP network70. The management system 74 is provided by the mobile network operatorfor managing the operation of the access point 50, including controllingthe available services.

For example, as mentioned above, and as described in more detail below,a user of the mobile phone 30 can establish a connection through theaccess point 50 over the Ethernet LAN 42 to one or more local PCs orservers 44, or through the IP gateway device 60 to another deviceconnected thereto, or through the IP gateway device 60 to a networkserver 72 connected to the IP network 70. These connections can beestablished without passing traffic over the core network 20 of thewireless communications network. The management system 74 is able todefine the devices, or the IP addresses, with which such connections canbe established. Then, these connections can be established with only arestricted number of devices or IP addresses, if desired by the mobilenetwork operator.

Also, the management system 74 is able to specify the channels (whichmay be defined by frequencies, time slots, and/or spreading codes,depending on the particular cellular wireless communications system)allocated to the access point 50. These channels may be allocatedsemi-permanently, or may be changed regularly, depending on therequirements of the network as a whole.

FIG. 2 is a block schematic diagram, showing the hardware architectureof the access point 50. The architecture consists of a number offunctional blocks interconnected by a processor bus 80 such as the ARMAMBA bus.

The access point 50 includes various external wired interfaces,including an RJ45 Ethernet 10/100 interface 82, which provides aconnection to a local LAN for connection to the IP gateway device 60 andthence to the MNO network and the Internet, and also provides access toother devices attached to the Ethernet network, such as one or more PC44, or such as an IPTV 64 for advanced service provision. The accesspoint 50 can therefore have an IP-based interface to the Radio AccessNetwork 10 through adaptation of the standard UMA UNC, or Core Networkvia SIP as opposed to the usual lub (UMTS) or Abis (GSM) interfaces.

The access point 50 also includes a Subscriber Identification Module(SIM) card interface 84 to allow use of a standard SIM card to provide aunique identifier for the access point 50, in order to identify the unitto the management system 74 and the operator's radio network 10 and corenetwork 20, and thereby enable various services to be provided.

The access point 50 also includes a Protocol Engine 86, implemented as asmall embedded CPU such as an ARM926 (with appropriate peripherals)supported by a dedicated co-processor 88 for encryption and a dedicatedco-processor 90 for packet processing, which will offload the main CPUfor specific intensive tasks. For example, encryption of the IPSecpacket payload is handled by the encryption accelerator 88, whichsupports AES and 3DES encryption protocols. The VPN connection of theaccess point 50 to the UNC 12 and the management system 74 will make useof the internal encryption processing; user VPN encryption processingmay be handled outside the access point 50.

The main CPU is also responsible for the configuration and control, viathe main CPU bus 80, of all functional blocks in the system including abaseband modem 92 and the Ethernet port 82. The system software image,including configuration data for all system functional blocks is storedin FLASH memory 94 within the access point 50; two complete systemimages are stored so that updated system images can be downloaded to theaccess point 50 from the management system 74, whilst the previous imageis retained as a fall back option in case of corrupted download accesspoint 50

The main CPU peripherals include: watchdog timers for software sanitychecking, JTAG and serial ports for in-system debug, and a GPIO forsystem control including LED status indication, system power managementand system alarm gathering.

The access point 50 has a first RF Interface 94 for GSM at either 900MHz or 1800 MHz and a second RF Interface 96 for UMTS at 2100 MHz. Ittherefore supports simultaneous operation of GSM and UMTS. For the GSMand UMTS receive paths both uplink (basestation receive) and downlink(terminal receive) frequencies are accessible; for the transmit pathsonly downlink (basestation transmit) frequencies are available. Atinstallation, the access point 50 selects a downlink RF carrierfrequency with the lowest noise/interference for both GSM and UMTS frompermitted lists of GSM and UMTS carrier frequencies provided by themanagement system 74; permitted downlink frequencies will be scanned bythe access point 50 with its receive path configured in UE mode and itstransmit path disabled.

The access point 50 is designed to provide cellular service over adistance of less than 50 m to stationary or pedestrian (for example, nomore than 10 km/h) users within a building, and hence the transmit powerrequired is dramatically reduced compared to a conventional macrocellbasestation. However, the functionality described herein can be providedin any basestation, operating at any power level, and handling any typeof mobile user.

The RF interfaces 94, 96 are connected through a modem analog interface98 to the baseband modem 92, which supports sample rate processing,chip-rate processing (UMTS only) and symbol rate processing for the GSMand UMTS basestation modems.

The access point 50 will have limited GSM Mobile Station (MS) and UMTSUser Equipment (UE) modem functionality, in order to allow the accesspoint 50 to recover the Broadcast Channel (BCH) from local GSM/UMTSbasestations and other nearby access points. UE modem mode will beentered during initial installation to survey the local RF environmentand at regular intervals after the initial installation to monitor theRF environment and, if necessary, modify the access point configuration.

The baseband modem 92 is implemented using a software-based architectureto ensure high adaptability over a field life of up to 5 years, forexample, being upgradeable to allow future enhancement to HSDPA or EDGEservice to be delivered in the field without the need to replace theunit.

The access point 50 includes timing and frequency references 100 whichprovide sufficient accuracy for GSM and UMTS basestation operation overa 5 year lifetime.

This embodiment of the access point 50 therefore provides variousoperational features. For example, it is user installable,self-configuring, and adaptive to the surrounding RF environment. Accesscan be restricted to specified users using standard GSM/UMTS protocols.Further, multiple access point units installed in a large indoor areaconnected to a common Ethernet LAN can manage handoffs betweenthemselves without the intervention of other systems in the radionetwork 10 or the core network 20 of the operator's cellular network.

FIG. 3 provides a conceptual overview of the architecture of thesoftware running on the protocol engine 86 of the access point 50,together with the encryption accelerator 88 and the packet processingaccelerator 90, with an emphasis on the Services Environment and itscontrol paths into the lower stack layers.

The access point 50 includes a services platform, which can exploit thepotential of the union of four data networks, namely the external MNOcore network 20, the external internet 70, mobile devices such as themobile phone 30 (via GSM/UMTS), and the home network (via Ethernet).

The access point stack architecture includes a powerful servicesenvironment 120. The services environment is Java-based and includes aJava Virtual Machine 122, and an access point library 124, in the formof an API interface which allows applications 126 to interact with thelower layers of the stack to control calls/data sessions, trafficrouting and many other functions. The services environment 120 alsoincludes a web server 128, which provides a convenient interface to theuser for configuration and monitoring and also for selection andpurchase of desired applications, with security protected options fordebug and maintenance via a local PC. The services environment 120 alsoincludes a management system (MS) client 130, which configures theaccess point 50 and monitors various aspects of its operation. The MSclient 130 controls the provisioning system so that any component of thesoftware in the system, as shown in FIG. 3, can be replaced andrestarted.

As mentioned above, the services environment 120 also includes variousapplications 126, for example created by the mobile network operator orthe IP gateway 60 provider, which can be pre-installed in the accesspoint 50, or can be delivered via download from the operator's networkat the operator's initiation or at user request, for example as part ofa chargeable service.

A network (ZN) layer 132 of the software provides session controlfunctions to manage and implement the service flows and policies thatdetermine how the access point 50 is configured and operates for anyparticular Mobile Network Operator (MNO) configuration and end-usersettings. Configuration parameters are loaded to the ZN database 134 viathe management system (MS) client 130, Java applications or via the WebServer 128. These parameters provide the “rules” for the session controloperation within the access point. Session control functions include:implementation of the policies for registration, call control andtraffic flow/routing for the access point 50 on the MNO core network;control of the UMA client (to be described further below) forregistration, call control and traffic flow; and efficient management ofaccess point access point resources in delivering GSM/UMTS services andinteracting with other services via the IP gateway 60.

Below the network (ZN) layer 132 of the software, there is the NonAccess Stratum (NAS) functionality 136, which is required in order forservices to be provided to the UE when the MNO GSM/UMTS core network 20is not connected to the access point 50. This functionality enables theaccess point 50 to offer the usual GSM/UMTS services, such as SMS andMMS which mobile users are accustomed to, whilst not being connected tothe GSM/UMTS core network in the conventional manner. In order for suchservices to be offered, the access point 50 contains a condensed subsetof the core network functions usually contained in the Mobile SwitchingCentre (MSC), Serving GPRS Service Node (SGSN), GSM BasestationSubsystem (BSS), and UMTS Radio Network Subsystem (RNS).

The Non-Access Stratum layer 136, as implemented in the access point 50,therefore provides various functions which are typically included in MSCand SGSN nodes within a conventional GSM/UMTS network. One such featureis call control (CC). This supports call establishment between two peerentities, mainly for circuit-switched connections.

The NAS layer 136 also provides session management (SM), for control ofpacket data sessions; Short Message Service (SMS) function, fortransmission of SMS messages between the access point 50 and the networkSMS service centre; supplementary services (SS), such as call waiting,call holding, and multi-party calling; Mobility Management/GPRS MobilityManagement (MM/GMM), for management of UE mobility elements, such aslocation registration, authentication, and ciphering; and controlfunctions associated with the SIM card which may be fitted to the accesspoint 50. The access point 50 also provides packet routing capability,which is essentially GGSN functionality in a conventional network.

Below the NAS functionality, there is the Access Stratum functionality,specifically the UMTS Access Stratum functions 138 and the GERAN AccessStratum functions 140. The UMTS Access Stratum functionality 138comprises some SGSN functionality, Radio Network Controller (RNC)functionality and an interface to the UMTS physical layer implemented onthe baseband modem 92. The RNC and physical layer interfacefunctionality is required for all access point services supporting UMTS,regardless of the core network interface used.

In more detail, the Access Stratum functionality comprises the followingelements:

Packet Data Convergence Protocol (PDCP)

Header compression and decompression of IP data streams (optional),transfer of user data, maintenance of PDCP sequence numbers (typicallypart of an SGSN function).

Radio Resources Control (RRC)

Broadcast of information related to the NAS and AS; establishment,maintenance and release of RRC connections; establishment,reconfiguration and release of Radio Bearers and radio resources; RRCconnection mobility functions; control of requested QoS; UE measurementreporting and control; outer loop power control; ciphering control.

Radio Link Control (RLC)

Transmission and reception of signaling and data packets, includingbuffering, segmentation and concatenation of packets. Comprises threeentity types, for acknowledged mode, unacknowledged mode, andtransparent modes.

Medium Access Control (MAC)

Mapping between logical channels and transport channels, selection ofthe appropriate Transport Formats for each Transport Channel, priorityhandling between UEs, multiplexing/demultiplexing of upper layer PDUsto/from transport block (sets) on common and dedicated transportchannels.

UMTS Layer 1

Interface to the UMTS modem functions implemented on the Baseband Modem.

The GERAN access stratum functionality 140 comprises BSS and somelimited SGSN functionality. The BSS functionality is required forsupport of all GSM/GPRS(EDGE services, regardless of the interface usedbetween the access point 50 and the MNO core network 20.

The SGSN functionality of the GERAN access stratum functionality 140comprises the following elements:

Sub-Network Dependent Convergence Protocol (SNDCP)

Multiplexing of several packet data protocols; datacompression/decompression (optional); header compression/decompression(optional); segmentation and re-assembly.

Logical Link Control (LLC)

LLC provides peer-to-peer unacknowledged and acknowledged data transfer,and the GPRS ciphering functionality.

The BSS functionality of the GERAN access stratum functionality 140comprises the following elements:

Radio Link Control/Medium Access Control (RLC /MAC)

RLC/MAC supports acknowledged and unacknowledged modes; segmentation andreassembly of LLC PDUs; multiplexing to several physical channels;broadcast of system information.

Radio Resource Management (RR)

RR connection establishment, maintenance, and releases; systeminformation broadcast; packet data resource management.

GSM/GPRS Layer 1

Interface to the GSM/GPRS/EDGE modem functions implemented in theBaseband Modem.

Thus, as described above, the access point 50 includes somefunctionality typically located in the higher levels of the Radio AccessNetwork for UMTS and GSM standards. This is partly because, in order tobe able to route data traffic to the MNO core network, or to theinternet or to devices on the local area network, the access point 50must have access to the data packets flowing to and from the remotedevices. However it is highly desirable that the air interface to thecellular devices is secured by the same ciphering mechanisms used in therest of the cellular network. Therefore, if it is required to maintainthis, then, in order to enable the service and routing capabilitiesdescribed above, the access point 50 should contain the terminationfunction for the air interface ciphering (namely, the RLC/MAC layer inUMTS).

The software running in the access point 50 also includes a UMA client142, allowing the access point 50 to use the UMA protocol in anon-standard configuration. Specifically, the standard UMA protocol isdesigned to enable a GSM MS or UMTS UE, which includes a UMA client andan unlicensed spectrum air interface such as IEEE802.11b/g or Bluetooth,to communicate with the GSM/UMTS core network using unlicensed spectrum.However, the implementation in the access point 50 uses the UMA clientas part of the network interface of a GSM/UMTS base station, so that theUMA protocols, developed to communicate with a GSM/UMTS core network viaan Unlicensed Network Controller (UNC), can be adapted to manage callshandled by that base station, including handover to/from the macronetwork. As noted previously, a SIP Interface can be used as analternative approach.

The access point 50 also includes one or more IP device clients 144, toenable the transfer of calls, control information or data between the“mobile domain” (mobile phones camped onto the access point 50 andtraffic paths into the MNO core network 20) and other IP devices, suchas a VoIP/POTS port within the IP gateway 60 for fixed-line phone/faxservices, an AV port within the IP gateway 60 for IPTV and/or videoservices, PC's or Servers 44 on the local Ethernet LAN, or remotewebpages and/or servers 72 accessible over the internet 70 via the IPgateway 60.

Each IP device client 144 has access to the traffic path within theaccess point 50 and can be controlled by the session controller in theZN layer 132, which can initiate and terminate calls/data sessions withthe accessible IP devices. The inclusion within the access point 50software architecture of IP device clients which are specific to aparticular device or service enables traffic from that particular deviceor service to be routed within the access point 50, such that it can beconnected to the GSM/UMTS mobile devices accessed via the GSM or UMTSAccess Strata or the MNO Core Network accessed via the UMA client.

Further, each IP device client 144 has access to the other devices onthe LAN, and also has access to other devices accessible over theinternet 70. For example, by using the appropriate IP device client 144,a POTS phone connected to the access point 50 can be connected over theinternet 70 to another POTS phone, in order to make a voice call.

Moreover, each IP device client 144 also has access to the mobilenetwork of the MNO. Specifically, any device connected to the LAN 42, orany device connected to the IP gateway 60, can have an IP device client144 that can associate itself with the SIM card connected to the USIMinterface 84. From the point of view of the MNO network, any such devicethen appears to be a mobile, and will be allowed access to providing adevice with appropriate desired functionality, and then using the SIMcard to allow the device to connect over the MNO core network to one ormore other devices.

A further use of the SIM card, connected to the USIM interface 84, is toallow the mobile phones camped onto the access point to work in asimilar way to a multi-extension cordless telephone system. In thisparticular service configuration, the SIM card within the access point50 carries an IMSI identifier which in fact identifies a phone line thehome or office within which the access point 50 is installed, althoughit appears within the mobile network operator's system as a mobilenumber. When the IMSI of the SIM card in the access point 50 is called,all mobile phones camped onto the access point 50 are rung until one ofthem is answered. In this way, incoming calls to an individual personwould be directed to the IMSI of that individual's mobile phone, and cantherefore be differentiated from calls which are intended for any of theusers in that home or office by the IMSI identifier which is called. Thecall handling functionality of the access point 50 then changes when theIMSI identifier of the access point itself is called.

Thus, in general terms, the access point 50 includes a UMTS SIM cardwhich is issued by the operator whose spectrum is used by the accesspoint, that is, the operator of the relevant mobile network. The USIMcard carries standard identification information for a Mobile Terminal,most significantly an IMSI identifier and an MSISDN number which is thetelephone number associated with the SIM. The IMSI identifier is used toidentify the access point, authenticate it and establish securecommunications with the MNO network via the IP interconnection usingexactly the same mechanisms as are used for Mobile Terminals containingSIM cards which access the MNO network via IP interfaces. A number ofstandard interfaces are defined for IP connection of terminal devicesinto a MNO Network, most commonly for Wireless LAN, or WiFi, deviceswhere the UMA and WLAN/IMS standard interfaces predominate. (So called“Pre-IMS” systems which supported IP devices including SIM cards canalso be interfaced to using this principle.) Procedures for theseinterfaces are described in more detail below but the principle extendsto any interface designed to support a remote device containing a SIMinto an MNO network.

Another capability that is enabled by the inclusion of a SIM within theaccess point 50 is that it is possible for the access point tocommunicate with the MNO network as a Mobile Terminal can do.Specifically, the access point is able to make and receive calls to/fromother mobile terminals or fixed line devices, to initiate and terminatedata sessions with other devices and to send and receive SMS and MMSmessages. This allows a number of useful functions to be supported bythe access point which include:

-   -   Reception of keyworded SMS messages from one of the users        pre-registered on the access point which can instruct the access        point to perform a specific function such as adding a new user        to the list of “permitted users” stored within the access point        (optionally the access point can update the management system 74        with this change to permitted users to maintain synchronism        between databases). This capability might be combined with an        application function and appropriate IP Device client within the        access point so that actions can be initiated on the user's home        network, such as programming a PC-based video recorder or        activating a burglar alarm or heating control.    -   Transmission of a SMS or MMS message to the user to alert them        to important information such as a new permitted user        successfully added to a access point, or a specific user        becoming camped on the access point (i.e. has arrived home) or        error conditions such as inability to provide service at        installation due to high levels of interference. This facility        could be combined with a access point application and        appropriate IP Device client 144 so that activity within the        user's home network can be relayed to the user when outside the        home; for example a photograph of a caller at the door of the        user's home taken by a security webcam could be forwarded to the        user as an MMS message.    -   Reception of a call/data session initiated by a user in wide        area network such that the user can access information on the        user's home network, for example live video from a security        webcam or browsing of information stored in the users home PC        server.    -   Initiation of calls/data sessions so that the access point can        “push” information to the user when triggered by an event or at        a predetermined time. For example, with a suitable IP Device        client 144 in the access point 50 and appropriate application        software in the access point and home PC server, multimedia news        clips downloaded onto the user's home PC can be forwarded to the        user's phone, or alerts generated by stock-tracking software or        internet auction sites can initiate a call to the user to invite        a response to the triggering event.

Messages, calls and data sessions initiated by the access point 50 aredirected into the MNO network so that they could be received by a userin the wide-area macrocell network; optionally, logic can be included inthe access point to identify if the recipient of the message/call/datasession is already camped on the cell so that the transaction can beinitiated directly over the air interface of the access point 50 withouttying up unnecessary core network resources. In a similar way, messages,calls and data sessions terminated by the access point 50 will bereceived direct from the core network; optionally the access point canscreen outgoing transactions to identify if its own MSISDN is theintended recipient for the transaction and thereby make a decision as towhether to intercept the call to avoid unnecessary use of core networkresources.

FIG. 4 is a block schematic diagram of a mobile communications network,in which the access point (AP) 50 is connected into the core networkusing a modified version of the existing standard UMA interface tosupport backhaul. This is referred to herein as 3G Licensed UMA (L-UMA)or 3G L-UMA. In FIG. 4, the access point (AP) 50 also includes thefunctionality of the IP Gateway 60 shown in FIG. 1.

The UMA or 3GPP GAN standard defines an interface between the GANCcontroller and the UE, the Up interface. The access point 50 uses thestandardised messaging to register and authenticate itself as a Mobiledevice and set up a secure IPSec tunnel to the core network.

FIG. 4 shows a single UE 30, although multiple UEs can camp on a singleaccess point 50. The UEs are 3GPP standard UMTS UEs with no additionalclient. They can be handsets, PDAs, PC cards or any other form factor.

The POTS or SIP phone 62 is used to make home number calls via theaccess point 50.

The PC client 44 controls local services preferences, contacts anddynamic calls/sessions behaviour. A softphone functionality can beincluded in the PC client.

The access point 50 provides the following functions:—

It provides local UMTS coverage at 3GPP standards.

It includes a USIM 160 dedicated to the access point 50 provisioning,configuration, authentication with the core network and to support UMTSservices for the home number service.

It interfaces with multiple UEs 30 over the 3GPP standard Uu interfaces,terminating locally AS and NAS layers.

It interfaces with local POTS or SIP phone 62 over a POTS interface orhome network/Ethernet interface to a standalone VoIP (SIP) phone.

It interfaces with local PC client 44 and softphone over IP via anEthernet interface 82.

It interfaces with other local or remote access points 162 via theItf-Zz interface.

It delivers local services without CN network signalling involvement,including local calls treatment and local Internet offload.

It interfaces with the L-GANC 164 over the Up′ interface, via theGeneric IP Access Network 70, for RRC-equivalent signalling and keyingmaterial exchange.

It interfaces with the CN legacy NEs (MSC 166, SGSN 168) on the 3GPPstandard Uu (NAS) interface, via the Up′ interface, for the NAS layerssignalling (MM, CC/SS/SMS, GMM, SM).

It interfaces with the management system (ZMS) 74 over the Itf-Zinterface, via the Generic IP Access Network 70 and L-GANC SecurityGateway 170, for network management, services management, softwareupgrades, fault reporting, activity monitoring and troubleshooting. TheItf-Z is connected via the L-GANC Security Gateway 170.

It interfaces with the public data network and the Internet 172 over theGi-L (local Gi) interface, to provide direct access to local data andlocal Internet offload service without core network involvement.

The Generic IP Access Network 70 provides IP connectivity between theaccess points 50, 162 and the L-GANCs 164 and between the access points50, 162 and the Internet 172. The Generic IP Access Network may applyNAT/PAT, and is generally conventional.

The 3G L-GANC 164 is the UMTS Licensed Generic Access NetworkController. The L-GANC 164 provides the following functions:—

It provides functionality equivalent to that of the RNC in the UMTSarchitecture.

It provides secure access over the Generic IP Access Network 70 to thecore network.

It includes a standard Security Gateway 170 for authentication and IPsectunneling.

It interfaces with the core network AAA 174 over the 3GPP standard Wminterface, for the support of authentication, authorisation andaccounting procedures.

It interfaces with multiple access points 50, 162 over the Up′interface, via the Generic IP Access Network 70, for RRC-equivalentsignalling and keying material exchange.

It provides a secure transport for the Itf-Z between the access point 50and the ZMS 74.

It interfaces with the core network MSC 166 over the 3GPP standard Iu-CSinterface, for the support of circuit switched services.

It interfaces with the core network SGSN 168 over the 3GPP standardIu-PS interface, for the support of packet switched services.

It provides a secure transport for the 3GPP standards Uu (NAS) interfacebetween the access point 50 and the core network MSC 166 and SGSN 168.

It interfaces with the core network SMLC 176 over the 3GPP standards Lbinterface, for the support of location information for the UEs roamingin the access point network

It interfaces with the core network CBC 178 over the 3GPP standardsCBC-RNC interface for supporting cell broadcast services.

The management system (ZMS) 74 provides OAM&P function for the accesspoint 50. More specifically:

It manages the access point 50 using the procedures and methodsdescribed in the DSL Forum TR-069 specifications.

It is responsible for the provisioning of the access point 50 during theinstallation process.

It monitors for faults reported by the managed access points.

It provides a means for the operator to manage the configuration of eachaccess point 50.

It provides user interface with security to restrict the functions towhich the user has access.

It interfaces with the access point 50 over the Itf-Z using a secure IPconnection.

It provides the means to manage the upgrade of the software for theaccess points.

It collects the performance metrics reported by the access points.

It interfaces Customer Care, and network operations centre.

The UMTS core network elements MSC 166, SGSN 168, AAA 174, and HLR/HSS180 are 3GPP standards elements, and will not be described further.

The access point 50 uses standard UE mechanisms to authenticate itself.This is illustrated using the IMS/SIP case as an example. The 3GPP IMSstandard includes a definition for an interface to support Wireless LANUEs containing SIM cards, referred to here as the WLAN/IMS interface. Asthe access point 50 includes a SIM card 160, it can appear as a WirelessLAN UE containing a SIM card, so that this mechanism can be reused toauthenticate the access point 50 with the MNO core network. Very similarmechanisms are included in non-standard so-called “Pre-IMS” solutionsmany of which are expressly designed to support incorporation ofWireless LAN devices within a conventional 3GPP network.

Thus, FIG. 5 is a diagram illustrating the standard WLAN/IMS interface,whereby a WLAN UE 190 authenticates itself with the Packet Data Gateway(PDG) 192 in a 3GPP network 194.

FIG. 6 is a diagram illustrating the adapted version of theauthentication mechanism used here. In essence the access point 50 usesthe same authentication mechanisms as are specified in the 3GPPstandards to authenticate itself with the AAA server and create a secureIPSec tunnel terminated at the Packet Data Gateway (PDG) 200.

The access point establishes an IPsec tunnel, specific to itself, to theHome Network. Thus, after the access point 50 is initialised it acquiresa local IP address from the ISP associated with the DSL access. Theaccess point 50 then needs a secure dedicated IP connection to the HomeNetwork for several purposes, such as remote configuration, providingVoIP support for a POTS phone, and secure delivery of UE-specific keyingmaterial when setting up a UE-specific IPsec tunnel on behalf of each UEthat attaches to the access point. This is achieved by setting up aVPN-like IPsec ESP tunnel towards the PDG 200 in the Home Network.

The access point leverages the fact that it contains a Home MNO Networkprovisioned USIM to establish this tunnel using IKEv2 with EAP/AKAauthentication in exactly the same way as a WLAN UE would in accordancewith R6 TS 23.234.

The following steps are performed at tunnel establishment:

1. The access point obtains the IP address of the PDG 200 in the HomeMNO Network.2. The access point uses IKEv2 with EAP-AKA authentication to setup theIPsec tunnel to the PDG 200 acquiring a Remote IP address in theprocess.

The access point is locally configured with a Fully Qualified DomainName (FQDN) pointing to the PDG 200, in similar fashion to a W-APN inthe WLAN 3GPP interworking framework. The access point 50 resolves theIP address of the PDG 200 via DNS procedures on the FQDN. It is assumedthat, as in the case of WLAN 3GPP interworking, the FQDN of the PDG 200exists in the public DNS.

The access point uses an IMSI-based Network Access Identifier, NAI, toidentify itself towards the Home MNO Network, e.g.0.<IMSI_ZAP>@.zap.mnc<MNC>.mcc<MCC>.3gppnetwork.org orIMSI_ZAP@.zap.home_network_domain.

Where:

IMSI_ZAP is the IMSI of the USIM located in the access point

MNC is the Home MNO Network Mobile Network Code and MCC is the MobileCountry Code

The prefix 0 can be used to indicated that AKA instead of SIMauthentication is requested

For the IKE-based tunnel setup procedure the access point will leverageIKEv2's native NAT transversal support, namely IETF RFC 3948“UDPEncapsulation of IPsec ESP Packets”, to deal with the (likely) fact thatthe access point is located behind a NAT device.

FIG. 7 shows the signalling involved in setting the IPsec tunnel betweenthe access point 50 and the PDG 200 in the Home MNO Network. Thisassumes a Home MNO Network architecture similar to that considered for3GPP-WLAN interworking. However, the solution does not strictly dependon the assumptions regarding network architecture, it suffices that thearchitecture supports the access point to PDG signalling as describedbelow. Although the tunnel establishment procedure between the accesspoint/USIM and the Home MNO Network is exactly as per R6 TS 23.234, itis described here in some detail so that the changes that are required(for delivery of UE-specific keying material to the access point) whenthe access point establishes UE-specific tunnels on behalf of each UEcan be described.

After the access point has resolved the PDG's FQDN into an IP address itinitiates the tunnel establishment procedure.

At step 701, the access point 50 sends the IKE_SA_INIT message from itsUDP port 500 to the UDP port 500 in the PDG 200. This message initiatesthe setup of the IKE SA between access point and PDG and it contains:

an SAi payload carrying the supported cryptographic suite(s), e.g. suite#2 in TS 33.234:

-   -   Encryption: AES with fixed key length in CBC mode;    -   Integrity: AES-XCBC-MAC-96;    -   Pseudo-random function: AES-XCBC-PRF-128;    -   Diffie-Hellman group 2        the access point's Diffie-Hellman (DH) public key, Kei, and a        nonce Ni;        the NAT_DETECTION_SOURCE_IP payload carrying the hash of the        source IP address (the access point's local IP address) and        source port (500);        an NAT_DETECTION_DESTINATION_IP payload carrying the hash of the        destination IP address (the PDG's IP address) and destination        port (500).

At step 702, the PDG 200 receives the IKE_SA_INIT message and proceedsto compute the hash of the source IP address and source port number ofthe packet carrying it. If it differs from the value in theNAT_DETECTION_DESTINATION_IP payload then the PDG knows that the accesspoint is behind a NAT. The PDG also computes the hash of its IP addressand port with that in the NAT_DETECTION_DESTINATION_IP payload. If thisdiffers then the PDG knows that it is itself behind a NAT and in thiscase it should start sending keep-alive packets to keep the NAT bindingsunchanged. The PDG generates its own NAT_DETECTION_SOURCE_IP andNAT_DETECTION_DESTINATION_IP payloads in the same way as the accesspoint did, in order to allow the access point to determine whether itand/or the PDG are behind NATs.

The PDG uses the received KEi and Ni together with its private DH keyand its own generated nonce Nr to generate seven secret shared keys:

-   -   SK_ai/SK_ar, to be used by the integrity protection algorithm        (AES-XCBC-MAC-96) to protect the IKE signalling    -   SK_ei/SK_er, to be used by the encryption algorithm (AES in CBC        mode) to protect the IKE signalling    -   SK_d, SK_pi/SK_pr

The PDG completes the negotiation of the IKE SA by sending theIKE_SA_INIT response. This is sent (from port 500 to port 500) to thesource IP address in the IP packet carrying the IKE_SA_INIT so as tomake sure it travels back to the access point irrespective of thepresence of NATs. This contains:

-   -   SAi payload carrying the access point-proposed cryptographic        suite thus acknowledging its acceptance    -   The PDG's Diffie-Hellman (DH) public key, KEr, and nonce Nr    -   The NAT_DETECTION_SOURCE_IP payload carrying the hash of the        source IP address (PDG's local IP address) and source port (500)    -   NAT_DETECTION_DESTINATION_IP payload carrying the hash of the        destination IP address (access point's IP address) and        destination port (500)

At step 703, when the access point receives the IKE_SA_INIT response itchecks the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IPpayloads in the same way as the PDG did to detect whether or not itand/or the PDG are behind NATs. If a NAT is detected then the accesspoint will switch to sending all future IKE signalling from port 4500 toport 4500.

The PDG uses the received KEr and Nr together with its private DH keyand its own generated nonce Ni to generate the same seven secret sharedkeys: as the PDG did before and starts protecting all future IKEsignalling with SK_ai/SK_ar and SK_ei/SK_er.

At this point the IKE SA has been setup and the access point and PDG cancommunicate securely but there has been no authentication. This isstarted by the access point by sending the first IKE_AUTH Requestmessage. The access point asserts its IMSI-derived identity through theIDi payload. It also declares its intention to use EAP for itsauthentication instead of the default IKEv2 authentication methods(pre-shared secret key-based or certificate-based) by not including anAUTH payload generated though one of these two methods.

The IKE_AUTH Request message also initiates the setup of the IPsec ESPSA (CHILD_SA) that will protect all the traffic to be carried over thetunnel. The message contains:

-   -   IDi payload with the access point's identity        IMSI_ZAP@.zap.mnc<MNC>.mcc<MCC>.3gppnetwork.org    -   IDr payload with the PDG FQDN    -   CP payload requiring a remote IP address at the PDG (to        terminate the IPsec tunnel) and potentially the IP address of        DNS servers located inside the Home MNO Network (e.g. for P-CSCF        discovery)    -   SAi2 which the initiator's (i.e. the access point's) Security        Association payload containing the cryptographic suite(s)        supported for protection of the traffic carried in the tunnel        (i.e through the IPsec ESP SAs), e.g. suite #2 in TS 33.234:    -   Encryption: AES with 128-bit keys in CBC mode.    -   Integrity: AES-XCBC-MAC-96;    -   Tunnel mode    -   TSi, TSr contain the proposed traffic selectors identifying the        IP flows (source range-destination range) to be carried over the        tunnel.

At step 704, the PDG asks the AAA server to authenticate the accesspoint by sending an EAP-Authentication Request message containing theasserted identity IMSI_ZAP@.zap.mnc<MNC>.mcc<MCC>.3gppnetwork.org

At step 705, if the AAA does not have a valid AKA authentication vector(RAND, AUTN, RES, CK, IK), it communicates with the HSS to obtain one.The HSS will run the AKA algorithm for the IMSI_ZAP for authenticationvector generation.

At step 706, the AAA server uses CK and IK to generate a Master SessionKey for that IMSI, (MSK_ZAP) and additional keys (TEKs) for protectingthe EAP-AKA packets

At step 707, the AAA server uses the AUTN and RAND in the vector toauthenticate itself and challenge the access point to AKA-authenticateitself by sending an EAP-Request/AKA-Challenge message carrying (RAND,AUTN) to the access point via the PDG. It also carries a MAC to allowthe access point to be sure that the EAP packet was not tampered with onthe way.

At step 708, the PDG forwards the EAP-Request/AKA-Challenge (RAND, AUTN,MAC) to the access point inside the IKE_AUTH Response message andincludes a certificate to authenticate itself towards the access point(in addition to the EAP-AKA based authentication to take place in step718).

At step 709, the access point uses its USIM to run the AKA algorithm i.eit:

-   -   Computes MAC to check that EAP message was not tampered with    -   Checks AUTN validity    -   Generates (RES, CK, IK)

In addition the access point computes MSK_ZAP point from CK, IK &IMSI_ZAP.

At step 710, the access point authenticates itself by sending the RESvalue in the EAP-Request/AKA-Challenge encapsulated in a new IKE_AUTHRequest message. It may also check the validity of the PDG'scertificate.

At step 711, the PDG forwards the EAP-Request/AKA-Challenge (RES) to theAAA server, which compares it with the RES value received from the HSSto authenticate the access point.

At step 712, if the authentication is successful then the AAA serverforwards the MSK_ZAP to the PDG in a EAP-Success payload encapsulated onthe successful Authentication Answer.

At step 713, the PDG asks the AAA server to authorize the access pointto enjoy the services associated with its FQDN (W-APN like).

At step 714, the AAA server checks the profile associated with theIMSI_ZAP to determine whether the tunnel can be set up.

At step 715, the AAA server confirms authorisation for tunnel setup.

At step 716, the PDG informs the access point that the authenticationwith the AAA server was successful by sending the EAP-Success payload inthe IKE_AUTH Response.

At step 717, the access point authenticates itself towards the PDG bysigning the IKE_SA_INIT message of step 701 with the MSK_ZAP key andincluding the result in the AUTH payload of a new IKE_AUTH Requestmessage.

At step 718, the PDG uses its knowledge of MSK_ZAP point to check theAUTH payload thus authenticating the access point. Then the PDG uses theMSK_ZAP to generate its own AUTH payload by signing the IKE_SA_INITresponse of step 702 so as to authenticate its identity towards theaccess point. The PDG sends this in the IKE_AUTH Response message. Inaddition the PDG sends the assigned Remote IP address of the tunnel inthe configuration payload (CFG_REPLY), and the negotiated cryptographicsuite (the same as the proposed one), SAr2 and traffic selectors TSi,TSr, thus completing the negotiation of the IPsec ESP SAs that willprotect all the traffic in the tunnel. Finally, the access point usesits knowledge of MSK_ZAP to check the AUTH payload thus authenticatingthe PDG.

The access point 50 includes client software functions for the UMA andWLAN/IMS interfaces (client software specific to particular non-standardPre-IMS solutions can also be included within the access point). Theclient functions allow the access point to appear to the MNO Network asa Terminal device as described above, but they also include interworkingfunctions to allow a standard GSM/UMTS terminal which is camped onto theaccess point 50 to appear as a UMA device or as a WLAN UE to the UMA orIMS interfaces respectively. (Again, the same principle can be extendedto proprietary Pre-IMS solutions based around SIP, which have a highdegree of commonality with SIP/IMS approaches). SIP and UMA clientsdeveloped for Mobile devices can be used as the basis of these clientfunctions—the great benefit to a mobile operator is that the clientswhich enable access over an IP network are supported in the access point50 and not in the phone, so that legacy phones can continue to be usedwith an IP-based access network reducing the operator's investment andimproving services for customers.

The air interface from the access point 50 to the Mobile Terminal shouldbe ciphered using standard GSM/UMTS procedures. To enable ciphering, theaccess point 50 needs access to cipher key information distributed fromthe MNO core network directly to the UE. To facilitate access to thecipher key information, small modifications have been made to thestandard mechanisms to allow the access point to use UE identificationto access the keys normally provided only to the UE. This process isinitiated only after the access point 50 has been authenticated by thecore network so that it is a “trusted element”. Furthermore, the keysobtained are temporary keys which must be refreshed for each call—masterkeys are not exchanged with the access point.

The implementation of this interworking principle for the UMA andSIP/IMS interfaces is described in more detail below.

One use of an interworking function is to support UE access and cipherkey exchange using UMA. As described above, the access point 50 connectsto the core network over a generic IP access network. There are twooptions for this connection, and the mobile network operators must beable to choose at the time of deployment between:

Secure IP access, where secure IPsec tunnels are applied for all accesspoint to core network communication, including access point specificIPsec tunnels and UE specific IPsec tunnels; and

Private IP access, where the MNO owns or has direct control of the IPaccess network, which is not going through any public PDNs, and, in thiscase, the MNO may want not to have the IPsec management and overheadsand may rely instead on the intrinsic security of the private IP access.

If the MNO requires secure IP access of the generic IP access network,the following applies. At power-on, the access point sets-up an IPsectunnel with the SeGW, using USIM-based authentication. The access pointIPsec tunnel is used to:

-   -   Support access point signalling and Network Management        functions;    -   Support the home number service, for non-UE calls (like POTS)        and fixed-line replacement

For each UE that roves-in the access point coverage, the access pointsets-up the UE-specific IPsec tunnel(s) with the SeGW, with USIM-basedauthentication (with the access point as the proxy). FIG. 8 shows anexample, showing the relevant part of the system of FIG. 4, where thereare a first UE (UE1) 210, and a second UE (UE2) 220. In this case, UE 1is a UE that offers CS services, connected with a high-QoS PDP context230 to the MNO data services (e.g. MMS), and connected with abest-effort PDP context 232 to the Internet via the GGSN, while UE 2 isa CS-only UE, e.g. a UE for which the end-user has not activated dataconnectivity.

In this example, the access point 50 sets up a respective tunnel foreach of the two UEs, namely a first tunnel 222 for the first UE 210, anda second tunnel 224 for the second UE 220. These tunnels carry the CStraffic and optionally the first PDP context. In this example, theaccess point 50 also sets up additional IPsec tunnels 226, 228 with theSeGW, for example for QoS differentiation of multiple/secondary PDPcontexts.

The access point 50 also instantiates a UE NAS and L-UMA client for CNsignalling, transparently to the legacy UE. Optionally, the access pointsupports local Internet offload.

In other examples, there may be one tunnel per access point and onetunnel per UE, or one tunnel per access point grooming all traffic (QoSdifferentiation on outer IP header), or no IPsec tunnels, but PPP orequivalent from the access point to the core network.

The high-level security architecture is specified in the following.

IP Networking Security

There is a firewall at the home router. Also, in the case of the SecureIP access option, but not the Private IP access option, allcommunications are secured via IPsec tunnels between the access pointand the CN Security GW, and there is one IPsec tunnel per access pointand at least one per UE, all with USIM-based authentication.

Access Point-Level Security

The access point authenticates with the management system 74 forservice; the access point registers with L-GANC, and the access pointauthenticates with CN MSC/SGSN for call/data services, using USIM-basedMM-layer authentication. Also, in the case of the Secure IP accessoption, but not the Private IP access option, the access pointauthenticates with the CN Security GW and sets up a USIM-based IPsectunnel.

UE-Level Security

Each UE is screened for access locally by the access point (by IMSI),the UE registers with L-GANC, the UE authenticates with CN MSC/SGSN forcall/data services, with the access point acting as a proxy, usingUSIM-based MM-layer authentication with MSC/SGSN, and there is cipheringon the radio interface between the UE and the access point, using IK, CKcaptured during MM authentication procedure. The MSC sends these to theL-GANC in the RANAP Security Mode Command, and the L-GANC forwards themto the access point on extensions of current GA-CSR (URR) messages or ona new dedicated message. Also, in the case of the Secure IP accessoption, but not the Private IP access option, the initial UE signallingwith the core network may be carried over access point-specific IPsectunnels, and the UE authenticates with the core network Security GW,with the access point (based on the USIM) acting as a proxy and settingup a UE-specific IPsec tunnel and optionally setting up additional IPsectunnels for secondary/multiple PDP context establishment, for QoSdifferentiation, unless only one IPsec tunnel per access point is used.

In the case of an access point IPsec tunnel establishment, when theSecure IP access option is used, the IPsec tunnel for the access pointuses a USIM-based authentication. No changes are required to thestandard IKEv2 and EAP-AKA procedure.

The access point IPsec tunnel establishment is followed by the accesspoint registration with the L-GANC, according to the standard procedure,and the access point MM authentication, again according to the standardprocedure.

In the case of the Secure IP access option, and provided there is notjust a single IPsec tunnel per access point, a UE IPsec tunnel isestablished. No radio ciphering is started at this stage, and theprocedure must be UE USIM-based.

After and IPsec tunnel has been set up, the access point L-UMA clientregisters the UE with the L-GANC following the standard procedure.

The radio ciphering is synchronised with the MM LAU procedure with theMSC. The ciphering keys (IK, CK) are stored in the access point at thisstage, using the ciphering material that the MSC has sent to the L-GANCin the IuCS RANAP Security Mode Command. The L-GANC forwards them to theaccess point on extensions of current GA-CSR (URR) messages or on a newdedicated message.

FIG. 9 illustrates in detail the procedure for performing an MM LocationArea Update and ciphering, in the case of a circuit-switchedregistration, where authentication and ciphering is enabled in the MSC.

In step 901, the UE 30 may perform a PLMN and/or cell selection/reselection in idle mode by sending a LOCATION UPDATING REQUEST messageto the access point 50. The message may contain the UE's IMSI or TMSI.

In step 902, the identification procedure may be initiated by the accesspoint in order to obtain the IMSI from the UE if only a TMSI wasreceived in the LOCATION UPDATING REQUEST message.

Step 903 is applicable only to the Secure IP access option (and notapplicable to the single IPsec tunnel per access point option),otherwise the procedure continues directly with step 904. The IKEv2 andEAP-AKA procedures are performed in order to set up the secure IPsectunnel between the access point and the UNC. During EAP-AKA theAuthentication and Security procedures will be performed. In this case,the SECURITY MODE messages are sent to the UE during the EAP-AKAprocedure.

In step 904, on successful establishment of the IPsec tunnel, the accesspoint generates and sends the URR REGISTER REQUEST message to the UNC inorder to register the UE on to the UNC. We assume that the serving UNChas already been discovered by the access point and, in step 905, theURR REGISTER ACCEPT message is received from the UNC indicating that theUE has successfully registered onto the UNC.

In step 906, the original LOCATION UPDATING REQUEST message receivedfrom the UE is transferred to the UNC in the URR UL DIRECT TRANSFERwrapper and, in step 907, the UNC transfers the LOCATION UPDATINGREQUEST to the MM sub-layer in the MSC.

Assuming that authentication and ciphering are enabled in the 3G MSC,then, in step 908, the MM sub-layer generates the AUTHENTICATION REQUESTmessage containing the 3G RAND and AUTN parameters and, in step 909, theUNC generates and sends the URR DL DIRECT TRANSFER message containingthe AUTHENTICATION REQUEST to the access point.

In step 910, the access point receives the URR DL DIRECT TRANSFER andsends the AUTHENTICATION REQUEST message to the UE.

In step 911, the UE performs the 3G authentication procedure, andgenerates the RES, which is sent to the access point in theAUTHENTICATION RESPONSE message. In step 912, the access point sends theAUTHENTICATION RESPONSE message in the URR UL DIRECT TRANSFER to the UNCand, in step 913, the UNC receives the URR UL DIRECT TRANSFER and sendsthe AUTHENTICATION RESPONSE message to the MSC.

In step 914, the RES contained in the AUTHENTICATION RESPONSE isvalidated in the MSC. The ciphering is enabled by sending the SecurityMode command to the UNC, which should contain the CK and IK Cipheringand Integrity keys. In step 915, the UNC sends the ciphering andintegrity information in a modified URR CIPHERING MODE COMMAND (or a newmessage URR SECURITY MODE COMMAND) to the access point.

In response, in step 916, the access point generates the SECURITY MODECOMMAND message containing the UEA (ciphering algorithm), UIA (integrityalgorithm), FRESH and MAC-I information. Note that the UEA, UIA, FRESH,and MAC-I could be sourced from the access point.

In step 917, the SECURITY MODE COMPLETE message is sent from the UE tothe access point and, in step 918, the access point generates themodified URR CIPHERING MODE COMPLETE message (or new URR SECURITY MODECOMPLETE message). In step 919, the UNC sends the CIPHER MODE COMPLETEmessage to the MSC.

In step 920, the MSC sends the LOCATION UPDATING ACCEPT message to theUNC and, in step 921, the UNC sends the URR DL DIRECT TRANSFER messageto the access point containing the LOCATION UPDATING ACCEPT and, in step922, the access point sends the LOCATION UPDATING ACCEPT to the UE tocomplete the registration procedure.

Thus, the L-GANC 164 forwards the ciphering keys to the access point 50for the radio encryption. The IuCS messages are the standard ones, theL-UMA messages are evolutions of the standard UMA ones.

As an alternative to the above, or in addition, an interworking functioncan be provided within the access point to support UE access and cipherkey exchange using the 3GPP WLAN/IMS interface. The access point-SIPframework re-uses those aspects of the 3GPP-WLAN interworking frameworkthat are valid for a generic IP access to 3GPP services and are not WLANaccess specific.

The fundamental concepts which are re-used are:

-   -   the use of an IKEv2-generated IPsec ESP tunnel as the IP        connectivity bearer to an access/security gateway in the Home        MNO Network, (in similar fashion as the PDP context when the        access NW is GPRS); and    -   the use of EAP-AKA/SIM based mutual authentication of the IPsec        tunnels.

For simplicity, the term PDG is re-used to denote the access/securitygateway in the Home MNO Network that terminates the tunnels, but ofcourse the gateway functionality does not have to be strictly the sameas that of 3GPP-WLAN PDG.

The access point will establish two kinds of IPsec tunnels to the PDG:one access point-specific tunnel (to handle all access point-relatedsignalling) and one or more UE-specific tunnels for each UE that isGSM/UMTS attached to the access point. Thus the illustrated accesspoint-SIP solution relies on the access point creating UE-specific IPsectunnels on behalf of the UE through which all UE-related traffic isexchanged with the Home MNO Network, such that the UE has seamlessaccess to the usual 3GPP CS and PS based services when it is GSM/UMTSattached to the access point.

The key issue to be handled in the establishment of these EAP AKA/SIMauthenticated UE-specific tunnels is that, while the access pointterminates the EAP signalling, it does not have direct access to the(U)SIM residing in the UE. While the access point can trigger theUE/(U)SIM to run the AKA/SIM algorithm by initiating a UMTS/GSMauthentication procedure (thus coupling the UE-access point GSM/UMTSauthentication procedure with access point-PDG tunnel authenticationprocedure) it will not have direct access to the keying materialgenerated in the UE/(U)SIM when the AKA/SIM is run. As such the accesspoint must obtain this keying material directly from the Home MNONetwork. Two alternative methods are described to achieve this, and eachmethod requires a slightly different interface structure between theaccess point and the Home MNO Network.

FIG. 10 illustrates a first architecture, which applies to the casewhere the “in-band” method of obtaining the UE-specific keying materialat tunnel establishment is used.

Thus, in the architecture shown in FIG. 10, there is a Uu interface 240between the UE 30 and the access point 50, a Wu′ interface 242 betweenthe access point 50 and the PDG 200, and a Wm interface 244 between thePDG 200 and the AAA server 174.

The Uu interface 240 is the usual GSM/UMTS air interface between the UEand the access point.

The Wu′ interface 242 is an enhanced version of the Wu interface definedin R6 TS 23.234. When used by the access point to establish an EAP-AKAauthenticated IPsec tunnel on behalf of itself (using the local accesspoint USIM) it is indistinguishable from the standard Wu interface.However, it can also be used by the access point to establish anEAP-AKA/SIM authenticated IPsec tunnel on behalf of a UE, in which caseadditional functionality is supported in order to allow the access pointto request the Home MNO Network to deliver the UE-specific AKA/SIMgenerated keying material.

This translates into defining three new proprietary attribute types forthe IKEv2 CFG_REQUEST payload type, two to carry the ciphering key (CK)and Integrity Protection key (IK) in case of AKA authentication and thethird one to carry the stand-alone ciphering key (Kc) in case of SIMauthentication.

The Wm′ interface is an enhanced version of the Wm interface defined inR6 TS 23.234. When used during the authentication and authorisation of aaccess point-specific tunnel it is indistinguishable from the standardWm interface. However, when used during the authentication andauthorisation of a UE-specific tunnel, additional functionality issupported in order to allow the AAA server to forward (to the PDG) theciphering key (CK) and Integrity Protection key (IK) in the case of AKAauthentication or the stand-alone ciphering key (Kc) in the case of SIMauthentication.

FIG. 11 illustrates a second architecture, which applies to the casewhere the “out-of-band” method of obtaining the UE-specific keyingmaterial at tunnel establishment is used. In this case, the access point50 needs a direct interface to the AAA server 174 in the Home MNONetwork in order to retrieve the UE-specific keying material at the timeof UE-specific tunnel establishment. Thus, in the architecture shown inFIG. 11, there is a Uu interface 250 between the UE 30 and the accesspoint 50, a Wu interface 252 between the access point 50 and the PDG200, a Wm interface 254 between the PDG 200 and the AAA server 174, anda Wax interface 256 between the access point 50 and the AAA server 174.

The Uu interface 250 is the usual GSM/UMTS air interface between the UEand the access point.

The Wu interface 252 is basically the same as the Wu interface definedin R6 TS 23.234, the only differences being regarding the format of theidentities used. The NAI used as the access point identity contains aspecific prefix in order to differentiate it from a WLAN UE. The NAIused as the UE identity is decorated with the identity (IMSI) of theaccess point, so as to make clear to the Home MNO Network that the UE isattached to that specific access point.

The Wm interface 254 is basically the same as the Wm defined in R6 TS23.234, the only differences being regarding the format of theidentities used to identify the access point and the UE attached to theaccess point as discussed in the previous section.

The Wax interface 256 is used by the access point to retrieve (from theAAA server) the UE-specific keying material that is generated when theAKA/SIM algorithm is run during the authentication of UE-specifictunnels. The protocol used is RADIUS or DIAMETER according to AAA serversupport. The Wax interface is a combination of the Wa and Wx interfacesdefined in R6 TS 23.234 for 3GPP WLAN Interworking. It is akin to the Wainterface in that it connects the access network (access point) to theAAA server in the Home MNO Network via an MA protocol. However itspurpose (to retrieve Authenticating Vector material CK and IK or Kc), issimilar to that of the Wx interface between the AAA server and the HSS.

The ultimate goal of the access point-SIP solution is to provideseamless support for the same services when the UE is GSM/UMTS attachedto the access point-SIP as those enjoyed when GSM/UMTS attached to theHome MNO Network via the macro cellular GSM/UMTS access network.

Since the UE is not able to access the Home MNO Network's 3GPP servicesover a generic IP access network, the access point performs this task onbehalf of the UE. For that purpose, the access point needs to establishIP bearers on behalf of the UE between itself and the Home MNO Networkfor carrying the UE-related traffic. The best way to achieve this is toestablish VPN-like IPsec ESP tunnels on behalf of the UE in much thesame way as defined for a WLAN UE in the WLAN-3GPP Interworkingframework for WLAN-3GPP IP Access (scenario 3) in 3GPP R6 TS 23.234.This is because, in this way, the access point makes each UE look like aWLAN UE to the Home MNO Network and so the Home MNO Network'sinfrastructure for WLAN-3GPP interworking can be re-used for the accesspoint-SIP access solution.

The tunnel management framework can be described as follows:

1. The access point will contain a database mapping GPRS APNs to PDGFQDNs on a 1-1 basis, i.e.:If GPRS APN x is mapped to FQDN x then FQDN x gives access to the sameset of 3GPP PS based services as would be available to the UE throughGPRS APN x, if it were located in the macro cellular GSM/UMTS accessnetwork.2. During the UE-initiated GSM/UMTS attach to the access point, thisestablishes a default IPsec tunnel to the PDG on behalf of the UE. Theauthentication and key generation procedures in the UE-access point andaccess point-PDG interfaces are coupled together by the access point.This tunnel is established towards a default (locally configured) FullyQualified Domain Name, FQDN_0, which identifies both the PDG and a setof services to be provided. The set of services supported by FQDN_0includes all the 3GPP CS based services normally available to the UEwhen camped on the macro cellular GSM/UMTS access network ,i.e., CSvoice calls, SMS etc. FQDN_0 may also support the 3GPP PS based servicesassociated with a specific GPRS APN.3. Subsequently, if the UE requests the activation of a PDP contexttowards a GPRS APN:

-   -   If there is no PDP context already active for that GPRS APN        (Primary PDP Context Activation Procedure) then the access point        checks the internal database of associations between GPRS APNs        and PDG FQDNs to see if that APN is associated with FQDN_0. If        that is the case then the existing IPsec tunnel is re-used. The        access point assigns the Remote IP address and internal DNS        server address associated with the existing tunnel to the PDP        context (i.e. it sends them in the ACTIVATE PDP CONTEXT ACCEPT).        If that is not the case, then the access point establishes a new        tunnel towards the FQDN associated with the GPRS APN and assigns        the Remote IP address and internal DNS server address associated        with that new tunnel to the PDP context (i.e. it sends them in        the ACTIVATE PDP CONTEXT ACCEPT)    -   If there is a PDP context already active for that GPRS APN        (Secondary PDP Context Activation Procedure) then the existing        tunnel is reused.

The access point automatically establishes a default UE-specific IPsectunnel towards FQDN_0 when the UE GSM/UMTS attaches to the access point.FQDN_0 provides at a minimum access to CS-SIP interworking for 3GPP CSbased services and may also provide access to the 3GPP PS based servicessupported for a specific GPRS APN.

The access point re-uses the IP address obtained from the resolution ofthe PDG's FQDN at the time of the establishment of the accesspoint-specific tunnel. In this way, the same PDG is used to terminateall the tunnels originating from the access point, i.e both the accesspoint specific tunnel and all UE-specific tunnels.

When the access point requests the establishment of the tunnel on behalfof the UE, the asserted identity used is composed by decorating the UE'sIMSI-based NAI with the access point's IMSI. In this way, both theidentity of the UE on behalf of which the tunnel is being requested andthe identity of the access point making the request are clear to theHome Network. In a similar fashion to that employed in the WLAN 3GPP IPaccess [See 3GPP R6 TS 23.003 “Numbering, addressing and identificationfor 3GPP System to WLAN Interworking”], the asserted identity is alsodecorated with a flag that indicates whether EAP AKA or EAP SIMauthentication should be used, e.g.0<IMSI_UE>@<IMSI_ZAP>.zap.mnc<MNC>.mcc<MCC>.3gppnetwork.org for EAP-AKA,or 1<IMSI_UE>@<IMSI_ZAP>.zap.mnc<MNC>.mcc<MCC>.3gppnetwork.org forEAP-SIM.

For the IKE-based tunnel setup procedure, the access point will leverageIKEv2's native NAT transversal support to deal with the (likely) factthat the access point is located behind a NAT device. Once the IPsec ESPtunnel is setup, the access point uses IETF RFC 3948 “UDP Encapsulationof IPsec ESP Packets” to deal with the fact that the access point islocated behind a NAT device.

The access point-SIP solution for setting up IPsec tunnels to the HomeMNO Network on behalf of the UE relies on two inter-locked securityprocedures for providing end-to-end security at the access networklevel.

Firstly, in the case of a UE performing a UMTS attach to the accesspoint, the access point performs mutual UMTS access authentication withthe UE/USIM on behalf of the Home MNO Network (HSS/HLR), as per R99 TS33.102 “3G Security; Security architecture”, and the access pointperforms mutual tunnel authentication with the Home MNO Network (withboth AAA server/HSS and PDG) on behalf of the UE/USIM, (as per IKEv2using EAP-AKA).

Secondly, in the case of a UE performing a GSM attach to the accesspoint, the access point performs GSM access authentication of the UE/SIMon behalf of the Home MNO Network (HSS/HLR), as per ETSI GSM 03.20:“Digital cellular telecommunications system (Phase 2+); Security relatednetwork functions”, and the access point performs mutual tunnelauthentication with the Home MNO Network (with both AAA server/HSS andPDG) on behalf of the UE/SIM, (as per IKEv2 using EAP-SIM).

In both cases the two procedures can be coupled because they both relyon running the SIM/AKA algorithms for authentication and generation ofkeying material for access layer encryption and integrity protection.However, the access point does not have direct access to any of theentities where the SIM/AKA algorithm is run, i.e., the (U)SIM of the UEor the HSS/HLR.

While the access point can perform mutual authentication with the AAAserver in the Home MNO Network on behalf of the UE/(U)SIM by mapping theEAP Request/Response exchange to the MM: Authenticate Request/Responseexchange, it still needs to obtain the keying material generated whenthe AKA/SIM algorithm is run, in order to perform authentication towardsthe PDG on behalf of the UE, as per IKEv2/EAP and in order to secure theGSM/UMTS air interface.

Considering performing authentication towards the PDG, it is generallythe case that, when EAP-AKA (encapsulated in IKEv2) is used forauthentication between two IKEv2 peers at (IPsec tunnel establishment),the mutual authentication is based on both peers proving to haveobtained the same shared secret as a result of the EAP AKA exchange.This shared secret is the Master Session Key, MSK, which is obtainedfrom the common CK and IK keys that were generated when the AKAalgorithm was run at both ends during the EAP AKA exchange.

In the current case, the PDG receives the Master Session Key from theAAA server. However since the access point cannot itself run the AKAalgorithm and has no way to obtain CK and IK from the UE/USIM itself,there must be an external way by which the access point obtains CK andIK necessary to authenticate itself towards the PDG on behalf of the UE.

The same applies in the case of EAP SIM authentication, substituting CKand IK with Kc.

Considering securing the GSM/UMTS air interface, when the UE performsUMTS registration to the access point, the access point must obtain thesame set of keys (CK, IK) for the UMTS ciphering and integrityprotection algorithms (between the UE and RNC) as that generated at theUE/USIM. A similar problem occurs in the case of GSM registrationregarding the ciphering key, Kc.

Thus, the access point requires access to CK and IK every time the AKAalgorithm is run between the UE/USIM and the HSS/HLR, and Kc every timethe “SIM” algorithm is run between the UE/SIM and the HSS/HLR.

As described here, the access point obtains those keys from the Home MNONetwork. The access point can obtain the keys from the Home MNO Networkduring the establishment of the IPsec tunnel on behalf of the UE, either“Out of band”; via the pre-existing connection between the access pointand the Home MNO Network based on the USIM located in the access pointitself, or “In band”, by piggybacking on the EAP signalling used to setup the tunnel on behalf of the UE.

In any of the solutions it is critical that these keys are transportedsecurely. This can be achieved by relying on the fact that there is apre-shared secret between the access point and the Home MNO Network,i.e., the MSK_ZAP which was generated at both ends when the access pointpreviously setup the IPsec tunnel with the Home MNO Network, based onits own USIM.

FIG. 12 illustrates the “In band” solution, where the keys are sent fromthe AAA server in the Home MNO Network to the access point (via thegateway) during the signalling to set up the UE-related IPsec tunnelitself. This requires some modification to the payloads of the IKEv2/EAPexchanges from those defined for the Wu and Wm interfaces in TS 23.234,in order to carry the keys.

The keys can be securely transmitted between the PDG and the accesspoint because there is a pre-shared secret between them, MSK_ZAP,generated at the time the pre-existing IPsec tunnel was establishedbetween the access point/USIM and the Home MNO Network.

When the access point requests the establishment of an IPsec tunnel onbehalf of the UE it asserts its identity as0<IMSI_UE>@<IMSI_ZAP>.zap.mnc<MNC>.mcc<MCC>.3gppnetwork.org in the caseof a UMTS attach, or1<IMSI_UE>©<IMSI_ZAP>.zap.mnc<MNC>.mcc<MCC>.3gppnetwork.org in the caseof a GSM attach.

In the case of a GSM attach, the access point requests the PDG todeliver the UE-specific ciphering key, Kc, by including an additional(proprietary) attribute, Kc_AT, in the CFG_REQUEST payload of theinitial IKE_AUTH Req message.

In the case of a UMTS attach, the access point requests the PDG todeliver the UE-specific ciphering and integrity keys (CK, IK), byincluding two additional (proprietary) attributes CK_AT and IK_AT, inthe CFG_REQUEST payload of the initial IKE_AUTH Req message.

The PDG then sends the Authentication request to the AAA server, quotingthe identity received in the IDi payload (and the FQDN_0 whichidentifies the access point for CS-SIP interworking).

From the fact that the IDi payload contains an IMSI (UE) decorated withanother IMSI (access point) the AAA server becomes aware that this isrequest for a UE-specific tunnel and not an access point-specifictunnel. As such, it knows that it must send the UE-specific keyingmaterial to the PDG in addition to the “usual” UE-specific MSK. Assumingthat the AAA protocol used between the PDG and the AAA server isDIAMETER (as required by 3GPP WLAN interworking) then, in the case ofAKA authentication, the AAA server may use the: “Confidentiality KeyAKA” AVP and “Integrity Key AKA” AVP.

In the case of SIM authentication, the AAA server may use the“Confidentiality Key AKA” AVP.

From the fact that the IDi payload associates the IMSI of the UE withthe IMSI of the access point, the PDG knows to retrieve the MSK_ZAP key,which it shares with the access point from the time of the establishmentof the access point-specific tunnel, to encrypt the UE-specific keyingmaterial received from the AAA server.

The PDG includes this material in the CFG_REPLY payload of the IKE_AUTHResponse that carries the EAP Success payload.

Since the access point also knows MSK_ZAP, it can decrypt the payload(s)and access the UE-specific keying material.

FIG. 13 shows the IPsec tunnel establishment signalling needed in orderto allow for the transport of the UE/USIM-related keys (CK, IK) to theaccess point in case of EAP-AKA authentication. This is based on thestandard IPsec tunnel establishment signalling (TS 23.234). A similarmechanism applies to EAP-SIM authentication.

Specifically, FIG. 13 shows how CK and IK can be carried from the HomeMNO Network to the access point at the time the UE-related IPsec tunnelis being established by the access point (on behalf of the UE). In step1301, as described above, every time the access point is powered on itestablishes an IPsec tunnel to a PDG in the Home MNO Network. Thisprocedure exactly follows the procedures defined in R6 TS 23.234 section6.1.5 “Mechanisms for the setup of UE-initiated tunnels (WLAN 3GPP IPaccess)”. As a consequence of this procedure, the access point, the PDGand the AAA server all share a secret key, the MSK_ZAP.

In steps 1302 and 1303, the access point and the PDG establish a newIKE_SA and agree on the IPsec protocols/algorithms used to secure theIKE signalling used to setup the UE-related IPsec tunnel.

The IKEv2 protocol provides a generic mechanism for one of the IKE peersto request the other peer for configuration information. This consistsin including a CFG_REQUEST payload in an IKE request listing therequested attribute. IKEv2 defines several default attributes, includingINTERNAL_IP4_ADDRESS, which is already used to obtain a remote IPaddress in the PDG necessary for the establishment of the IPsec tunnel.However IKEv2 allows the extension to new proprietary attribute types.In this solution, we define two additional attributes CK_AT and IK_AT tobe used by the access point in step 1304 to request the PDG to supplythe necessary CK and IK associated with the UE. Additionally, in orderto allow the Home MNO Network to understand that this tunnelestablishment procedure is associated with this specific access point,the access point decorates the UE's NAI with its own IMSI, i.e,0<IMSI_UE>@<IMSI_ZAP>.zap.mnc<MNC>.mcc<MCC>.3gppnetwork.org.

Thus, if the IMSI of the USIM in the access point is 234150999999999 andthe IMSI of the UE's USIM is 234150888888888, then the access pointasserts the following identity on behalf of the UE:IDi=0234150888888888@234150999999999.zap.mnc234.mcc15.3gppnetwork.org

Following the 3GPP-WLAN convention (R6 TS 23.003), the 0 prefix signalsthat EAP_AKA is to be used. A prefix 1 would signal EAP-SIM.

Since IDi contains the access point's IMSI the PDG can retrieve thepre-shared secret between the access point and the GW, i.e., MSK_ZAP andthus use it to encrypt the UE-related CK and IK when these are receivedfrom the AAA server later in the signaling.

In step 1306, the AAA server checks whether it has a stored AKAauthentication vector (RAND, AUTN, XRES, CK, IK) associated with theUE's IMSI. If not, it queries the HSS for new ones.

When the AAA server reads this special form of IDi it knows that forthis case it must send the CK and IK associated with the UE's IMSI tothe PDG so that is eventually sent to the access point. This in additionto the MSK_UE that is generated by the AAA as usual from the CK and IK.

In step 1308, the access point maps the EAP-Request/AKA-challenge (RAND,MAC, AUTN) into MM: Authenticate Request (RAND, MAC, AUTN) and sends itto the UE so as to trigger the running of the AKA algorithm.

In step 1309, the access point receives MM: Authenticate Request (RES,MAC) from the UE and maps it to the EAP-Response/AKA-challenge (RES,MAC) which will authenticate the UE vis a vis the AAA server.

In the standard signalling (TS 23.234 section 6.1.5), the AAA serverwould only deliver the Master Session Key associated with the UE's IMSI.However, in this case, in step 1311, the AAA server adds two extra AVPs,namely the Confidentiality Key AKA, and the Integrity Key AKA to theAuthentication Answer, so as to make CK and IK available in the PDG.

If the tunnel is authorized in steps 1312-1314, in step 1315 the PDGdelivers the CK and IK to the access point via the CFG_REPLY payload,which will now carry the CK and IK attributes in addition to the remoteIP address.

In order to make sure that only the access point can access the CK andIK, the PDG encrypts the keys with the pre-shared secret, MSK_ZAP. Thiscan be achieved in a number of ways but the specific way needs to beagreed with the Home MNO Network provider.

In step 1316, the access point uses the shared secret MSK_ZAP to decryptthe CK and IK payloads. The access point can then generate MSK_UE (asdefined in [EAP-AKA] section 6.4 “Key generation”), which is used togenerate the correct AUTH payload (as defined in [IKEv2] section 2.16“Extensible Authentication Protocol Methods”).

On the other hand the access point uses CK and IK for encryption andintegrity protection over the air interface.

In step 1317, the PDG checks the AUTH thus authenticating the tunnel andgenerates its own AUTH payload. The access point uses the MSK_UE tocheck the validity of the AUTH thus authenticating the PDG.

As shown in FIG. 11, and described with reference thereto, a differentarchitecture apples in the case of the “Out of band” solution. In thissolution, during the UE-specific tunnel establishment, the access pointobtains the UE-specific keying material by directly querying the AAAserver in the Home MNO Network for the necessary UE-specific keyingmaterial, i.e. CK and IK in case of UMTS attach and Kc in case of GSMattach. This query is performed via RADIUS or DIAMETER via the Waxinterface described above, and introduced to support the accesspoint-SIP solution.

In this solution the UE-specific tunnel establishment follows the sameprocedure as that shown in FIG. 13, up to the point at which the accesspoint receives the IKE_AUTH Response carrying the EAP Success message,which signals to the access point that the AAA server has successfullyperformed the EAP authentication for the UE. At this point, the accesspoint needs to retrieve the UE-specific keying material from the AAAserver so as to authenticate itself towards the PDG and start usingciphering and integrity protection over the air interface. This materialis part of the authentication vector used by the AAA server during thesuccessful EAP-based mutual authentication between the access point (byquerying the UE with the GSM/UMTS Authentication Procedure) and the AAAserver that just took place.

Where DIAMETER is used, then the application defined in TS 29.234 forthe Wx interface of the 3GPP WLAN interworking framework, for AAA serverretrieval of authentication vectors from HSS, can be re-used.

The access point 50 sends an Authentication Request to the AAA server,having the format:

Information element name Mapping to Diameter AVP Value Permanent UserIdentity User-Name IMSI_UE Visited Network IdentifierVisited-Network-Identifier IMSI_ZAP Number AuthenticationSIP-Number-Auth-Items 1 Items Authentication Data SIP-Auth-Data-Item Seetable below

The Authentication Data content in the request has the format:

Information element name Mapping to Diameter AVP DescriptionAuthentication Method Authentication Method EAP/SIM or EAP/AKA

The AAA server sends an Authentication Answer to the access point 50,having the format:

Information element name Mapping to Diameter AVP Value Permanent UserIdentity User-Name IMSI_UE Visited Network IdentifierVisited-Network-Identifier IMSI_ZAP Result Result-Code/Experimental-Success Result Authentication Data SIP-Auth-Data-Item See tables below

The Authentication Data content in the answer, in the EAP-AKA case, hasthe format:

Information element name Mapping to Diameter AVP DescriptionAuthentication Method Authentication Method EAP/AKA Confidentiality KeyAKA Confidentiality -Key CK Integrity Key AKA Integrity-Key IK

The Authentication Data content in the answer, in the EAP-SIM case, hasthe format:

Information element name Mapping to Diameter AVP DescriptionAuthentication Method Authentication Method EAP/AKA AuthenticationInformation Authentication Information concatenation SIM SIM ofauthentica- tion challenge RAND and the ciphering key Kc

There are therefore described methods whereby a base station providedwith a SIM card can authenticate itself to a network,

1. A base station for a cellular communications system, comprising aninterface for a SIM card.
 2. A base station as claimed in claim 1,including SIP client software, such that communications in accordancewith a GSM/UMTS protocol can be mapped onto corresponding SIP services.3. A base station as claimed in claim 1, including UMA client software,such that the base station can communicate over a broadband IP networkwith a UMA UNC in the core network of the cellular communicationssystem.
 4. A base station as claimed in a claim 3, wherein software inthe base station is adapted to map communications in accordance with aGSM/UMTS protocol to the UMA protocol.
 5. A base station as claimed inclaim 1, including IPSec software, whereby the base station is able toprovide an encrypted and secure transmission medium between the basestation and a core network of the cellular communications systems.
 6. Abase station as claimed in claim 5, wherein the base station is adaptedto receive ciphering keys from the core network of the cellularcommunications system.
 7. A base station as claimed in claim 6, whereinthe base station is adapted to cipher and decipher messages transmittedbetween the base station and a mobile station, using at least oneciphering key received from the core network of the cellularcommunications system.
 8. A base station as claimed in claim 1, whereinthe base station is adapted to use identifying data stored on the SIMcard to identify itself to a core network of the cellular communicationssystem, such that it is recognized as a mobile device and is enabled tooriginate and terminate messages and cells.
 9. A base station as claimedin claim 8, wherein the base station is adapted to use the identifyingdata stored on the SIM card to set up an IPSec tunnel with the corenetwork of the cellular communications system.
 10. A base station asclaimed in any preceding claim, wherein the base station is adapted toact as a proxy for any communications device connected thereto over awireless communications protocol, such that the communications device isenabled to communicate with a core network of the cellularcommunications system.
 11. A base station as claimed in claim 1, whereinthe base station is adapted to receive and act upon an SMS message froma pre-registered user, instructing the base station to perform aspecific function.
 12. A base station as claimed in claim 11, whereinthe specific function comprises maintaining a database.
 13. A basestation as claimed in claim 12, wherein the base station is furtheradapted to update an associated management system with any changes tosaid database.
 14. A base station as claimed in claim 11, wherein thespecific function comprises controlling a device connected to a user'sLocal Area Network.
 15. A base station as claimed in claim 1, whereinthe base station is adapted to send an SMS or MMS message to a user, inresponse to a predefined condition.
 16. A base station as claimed inclaim 15, wherein the predefined condition relates to operation of thebase station.
 17. A base station as claimed in claim 15, wherein thepredefined condition relates to a device connected to a user's LocalArea Network.
 18. A base station as claimed in one of claims 15 to 17,wherein, if a mobile communications device of the user is camped on thebase station, said SMS or MMS message is sent to said user directly,without passing through a core network of the cellular communicationssystem.
 19. A base station as claimed in claim 1, wherein the basestation is adapted to receive and act upon a call or data sessioninitiated by a user in a wide are network, such that the user can accessinformation on the user's Local Area Network.
 20. A base station asclaimed in claim 1, wherein the base station is adapted to initiate acall or data session to a user, in response to a predefined condition.21. A base station as claimed in claim 20, wherein the predefinedcondition relates to a device connected to a user's Local Area Network.22. A base station as claimed in one of claims 20 to 21, wherein, if amobile communications device of the user is camped on the base station,said call or data session is initiated with said user directly, withoutpassing through a core network of the cellular communications system.